1. Field of the Invention
The present invention relates to transaction debugging and more particularly to trace debugging of failed transactions in a transaction processing system.
2. Description of the Related Art
A transaction processing system is a type of information system that collects, stores, modifies, and retrieves organizational transactions. In this regard, a transaction is an event that generates or modifies data that is eventually stored in an information system. To be considered a transaction processing system the “ACID” test must be satisfied. In this regard, the “ACID” test refers to a test for atomicity, consistency, isolation, durability as a set of properties that guarantee database transactions are processed reliably.
The essence of a transaction processing system is that the data of the transaction processing system data must be left in a consistent state. That is to say, for a compound transaction, for the transaction to complete successfully, all portions of the transaction must complete successfully. Otherwise, any changes resulting from the partial completion of the transaction must be “rolled back” to the state that existed prior to the initiation of the compound transaction. While this type of integrity must be provided also for batch transaction processing, it is particularly important for real time processing. Other transaction monitor functions include deadlock detection and resolution resulting from cross-dependence on data, and transaction logging in trace logs for forward recovery in case of transaction failures requiring debugging.
A busy transaction processing system can process many millions of transactions each day. When a problem arises, end users often must resort to sophisticated vendor provided technical support to execute trace operations to capture trace log data with respect to a recognized failure. Consequently, a trace is captured and sent to technical support—typically by electronic means. The problem then becomes one of diagnosing what has gone wrong.
Of note, the trace is typically not large enough to span more than a very short time period, perhaps only a few seconds of clock time even for a large trace data set on a busy system. The transaction which caused the reported failure may be seen, but without a trace log that includes for comparison purposes, data from a previously successfully completed instance of the transaction, it can be very difficult to diagnose what has gone wrong. The absence of trace data for a previously successful completion of a failed transaction can make problem diagnosis difficult, resulting in unnecessary and burdensome interactions between the customer and technical support which can be irritating from the view of the customer and costly from the view of the vendor.